[00:00.000 --> 00:05.700]  of ATT&CK for ICS, and that's what I'll be talking about today, give you a little introduction,
[00:05.700 --> 00:10.920]  and also talk about some use cases centered around testbeds, which I think is relevant to
[00:10.920 --> 00:17.220]  the ICS village. So feel free to use the link here, ATT&CK.Meijer.Org for slash ICS,
[00:17.220 --> 00:21.000]  if you want to take a look at the knowledge base while I'm talking,
[00:21.000 --> 00:24.400]  and also feel free to reach out to me on Twitter.
[00:26.400 --> 00:35.940]  So ATT&CK for ICS was released this year in January, and the real purpose of this knowledge
[00:35.940 --> 00:42.700]  base is to look at how adversaries have affected critical infrastructure in the past. So really
[00:42.700 --> 00:49.340]  looking at their behaviors, tactics, techniques, and procedures associated with the attacks, and
[00:49.340 --> 00:57.880]  what the ultimate impacts of those attacks are. So since its release, we've gotten a lot of
[00:57.880 --> 01:06.600]  adoption, a lot of attention. Some of the security vendors here have released blog posts and
[01:06.600 --> 01:13.080]  presentations showing how they use ATT&CK for ICS and how they envision their customers using it.
[01:13.080 --> 01:18.940]  Also, asset owners and operators are looking at how they can use it to kind of fill gaps and to
[01:18.940 --> 01:25.600]  understand their environments a little bit better. So for those who aren't familiar with
[01:25.600 --> 01:33.460]  ATT&CK, what is ATT&CK? Well, it's a knowledge base of adversary behavior, and it's based on
[01:33.460 --> 01:39.620]  real-world observation. So that's what adversaries are doing in the wild, what credible red teamers
[01:39.620 --> 01:46.340]  are doing, and things like that. I think good news for everybody is it's free, open, and globally
[01:46.340 --> 01:54.120]  accessible. So I gave you a link at the beginning, ATT&CK.meyer.org for slash ICS. Any of you can go
[01:54.120 --> 02:02.120]  and look at the knowledge base at any time. It also provides a common language for how we talk
[02:02.660 --> 02:11.440]  between defenders, red teamers, to business people. It really allows us to all get on the same page,
[02:11.440 --> 02:17.480]  and I think that's very important for especially testbed activities when you have red teamers and
[02:17.480 --> 02:25.820]  blue teamers. And it's community-driven, so we always look forward to contributions from the
[02:25.820 --> 02:32.100]  community. If you think that there's something missing or if you know of some adversary activity,
[02:32.100 --> 02:37.940]  you could always submit that and be a contributor to ATT&CK in general.
[02:39.520 --> 02:48.340]  So this is a common representation of ATT&CK. You'll see this across the multiple technology domains and
[02:49.360 --> 02:57.320]  knowledge bases. This is a technique matrix. And across the top, you have what are called tactics,
[02:57.320 --> 03:03.560]  which are the adversary's technical goals. So this ranges here on the ATT&CK for ICS technique
[03:03.560 --> 03:10.920]  matrix from initial access to discovery to inhibit response function and peer process control
[03:10.920 --> 03:17.360]  impact. So those are some technical goals of the adversary. And associated with each of these
[03:17.360 --> 03:25.160]  technical goals are techniques, and this is how the goal is accomplished. So this could be data
[03:25.160 --> 03:31.840]  historian compromise under initial access. It could also be device restart or shutdown under
[03:31.840 --> 03:38.760]  inhibit response function. And associated with each of the techniques, if you go to the site
[03:38.760 --> 03:45.320]  and look at a particular technique page, is some specific technique implementation. And this is how
[03:45.320 --> 03:51.380]  the adversary accomplished this high level technique. So looking at this all together,
[03:51.380 --> 03:57.260]  you have the tactics, techniques, and procedures of adversaries, which really represents their
[03:57.260 --> 04:07.660]  behavior and is the focus of ATT&CK. So on ATT&CK.meyer.org, you'll see a number of
[04:07.660 --> 04:12.360]  knowledge bases that are associated with technology domains. So you'll see
[04:13.400 --> 04:19.220]  enterprise, you'll see cloud, you'll see mobile, and now you see ICS up there as well.
[04:19.220 --> 04:26.040]  Why do we have different knowledge bases? Well, in general, adversary motivations may be different
[04:26.040 --> 04:34.200]  and they may be tightly coupled to the technology domain that they are targeting. So gaining access,
[04:34.200 --> 04:39.440]  accomplishing your objective, all depends on the target and what you're actually going for.
[04:39.440 --> 04:44.520]  So there's going to be some differences between enterprise systems and cyber physical systems.
[04:44.520 --> 04:50.540]  There's also different phases in the life cycle, which means there's different choices. So that
[04:50.540 --> 04:56.000]  also influences our decision to create a new knowledge base. And then when we get to the
[04:56.000 --> 05:01.720]  technologies, there's some real differences there. So how the adversaries interact with particular
[05:01.720 --> 05:07.580]  systems really depends on that system. So how an adversary moves through an enterprise system
[05:07.580 --> 05:14.960]  is different than how they may affect an embedded controller or something like that. It's things
[05:14.960 --> 05:21.880]  that we have to take into consideration. And then when we get to defense, we have to think about
[05:21.880 --> 05:29.860]  how are we collecting data to get information about what adversaries have done. We can always
[05:29.860 --> 05:35.500]  use network data, but what about low-level devices? How do we collect data from them?
[05:35.500 --> 05:40.900]  Are there standard interfaces for collecting that data? What can we expect from them?
[05:40.900 --> 05:46.660]  Also, in terms of mitigations, we don't want to recommend mitigations that are going to conflict
[05:46.660 --> 05:52.200]  with safety or availability of the system. So we really have to think hard about that. These are
[05:52.200 --> 05:57.800]  all just some high-level reasons why we came up with a different knowledge base to really talk
[05:57.800 --> 06:06.220]  about adversaries in the ICS technology domain. So this is a representation of an industrial
[06:06.220 --> 06:13.000]  control system. Most of us are familiar with it as a Purdue reference architecture. We think of it
[06:13.000 --> 06:18.380]  as functional levels of an industrial control system. And some of these levels are associated
[06:18.380 --> 06:24.960]  with traditional IT, and some of them are more operational technology focused, although they have
[06:24.960 --> 06:31.880]  IT elements in them. So when we're looking at an incident and we're decomposing it or mapping it
[06:31.880 --> 06:39.200]  to ATT&CK, what we first do is try to think about what technology domain the adversary affected
[06:39.200 --> 06:45.720]  first. And sometimes that's the enterprise technology domain. So what we'll do is we'll
[06:45.720 --> 06:51.640]  use enterprise ATT&CK to go as far as we can in terms of explaining the adversary behavior.
[06:51.640 --> 06:56.440]  As we get down to the lower levels and we start talking about specialized protocols, specialized
[06:56.440 --> 07:03.560]  applications, and specialized equipment, we really need ATT&CK for ICS to tell the rest of the story.
[07:03.560 --> 07:12.020]  So it really fills in the entire picture. So back to the technology technique matrix for ATT&CK for
[07:12.020 --> 07:20.760]  ICS. Let's break it down really quick. So if we look at the first tactics, a couple of tactics or
[07:21.360 --> 07:27.740]  it really represents the adversary finding their target, collecting information, and ultimately
[07:27.740 --> 07:34.820]  staging an attack. So initial access is how we get in. We may try to find our target by using
[07:34.820 --> 07:41.520]  discovery techniques. And then we may need to get specific information. So we may have to do some
[07:41.520 --> 07:46.420]  collection to understand the state of the system or state of the process at any point in time.
[07:47.080 --> 07:52.320]  Then inhibit response function and impair process control is the adversary directly
[07:52.320 --> 07:57.620]  affecting the control system. So this is us sending unauthorized command messages. Maybe
[07:57.620 --> 08:03.200]  we do a program download with a malicious program, different things like that, in order to actually
[08:03.700 --> 08:10.620]  affect the control system. And last, we have our impacts, which is really what the adversary is
[08:10.620 --> 08:15.980]  seeking to create. Are we trying to create a loss of control? Are we trying to damage property as
[08:15.980 --> 08:22.800]  an adversary? This tactic really contains those types of techniques. So this is just a quick
[08:22.800 --> 08:31.520]  breakdown of ATT&CK and ATT&CK for ICS and what's contained in it. It's really based off of what
[08:31.520 --> 08:36.960]  we've seen in the wild. So that could be kind of limiting for us, especially if we want to have fun
[08:36.960 --> 08:42.740]  in a testbed environment or learn about what particular techniques look like. So what I'll
[08:42.740 --> 08:48.580]  be talking about next is a way that we can kind of structure our activities in a testbed environment,
[08:48.580 --> 08:56.100]  specifically on ICS Village when we're working in it as adversaries. So something that we can use
[08:56.100 --> 09:03.200]  are failure and ATT&CK scenarios. I'll explain what those are and how they can help structure
[09:03.200 --> 09:10.660]  our activities. So failure scenarios include malicious and non-malicious cybersecurity
[09:10.660 --> 09:16.640]  events. And these can range from compromising equipment functionality to data integrity
[09:16.640 --> 09:24.180]  attacks to communication failures and more. And these have a lot of uses. They can be used for
[09:24.180 --> 09:29.800]  risk assessment. They can be used for training. Tabletop exercises is something that they're
[09:29.800 --> 09:36.140]  very popular for. But they can also be used for like security tests and testbed. So examples of
[09:36.140 --> 09:42.520]  sources of data for failure scenarios, really understanding how these systems fell and where
[09:42.520 --> 09:47.580]  are the causes of them could come from subject matter experts. So people who operate these
[09:47.580 --> 09:54.280]  systems. It could also come from researchers. They could come from incident repositories. So how do
[09:54.280 --> 10:01.060]  real life systems fail and what were the causes and consequences of those failures? So this could
[10:01.060 --> 10:10.020]  be NTSB databases, FEMSA or pipeline databases, or even more. And then there's also scenario
[10:10.020 --> 10:15.520]  repositories. These are subject matter experts have gotten together and talked about different
[10:15.520 --> 10:21.440]  failures that can happen. And they've provided us a repository of failures that we can just work
[10:21.440 --> 10:28.500]  from, such as the every NEST Core failure scenarios. So let's look at some example failure scenarios.
[10:28.500 --> 10:35.680]  These come from researchers who are power engineers and they released a research document
[10:35.680 --> 10:42.840]  through the IEEE that kind of details some failure scenarios that are interesting. So scenario one
[10:42.840 --> 10:50.900]  is transformer overloading. So in this particular scenario, what the objective of the adversary is,
[10:50.900 --> 10:56.440]  is to rapidly deteriorate transformer installation. And this really represents one of those low and
[10:56.440 --> 11:02.640]  attacks that damage long lead time pieces of equipment. So the technique here is basically to
[11:04.500 --> 11:11.260]  set or modify trip settings so that if there's an overcurrent or thermal condition that the
[11:11.260 --> 11:18.320]  protective relay doesn't step in to kind of correct the condition. Then we also want to
[11:18.320 --> 11:23.340]  block communications so that operator doesn't understand what's going on. And then we want to
[11:23.340 --> 11:30.140]  force all the power through one transformer to bear the load. So this rapidly heats up the
[11:30.140 --> 11:36.400]  transformer and degrades its installation. Scenario two, we're disrupting switching execution for
[11:36.400 --> 11:43.420]  circuit breaker and isolators and we're causing dielectric breakdown of that breaker and isolator.
[11:43.420 --> 11:49.600]  So what we're doing here is we're continuously executing switching actions to take this piece
[11:49.600 --> 11:55.580]  of equipment out and we're blocking comms to kind of hide our actions. And then scenario three is
[11:55.580 --> 12:02.480]  kind of that typical Ukraine type attack where we're just opening breakers and we're trying to
[12:02.480 --> 12:10.380]  cause entire substation outages and whatever contingencies come along with it. So we can start
[12:10.380 --> 12:16.920]  to structure this failure scenario so that we understand exactly what we're trying to accomplish.
[12:16.920 --> 12:22.500]  If we take scenario one, the transformer overloading, we can think about what the consequence is. The
[12:22.500 --> 12:27.580]  consequence is a thermal breakdown of transformer installation. Then we have a couple failure modes.
[12:27.580 --> 12:36.000]  We don't want the protector relay to trip. So we're going to put improper overcurrent and
[12:36.000 --> 12:40.980]  thermal settings in it. And then we also want one of the transformers to bear all the load. So we
[12:40.980 --> 12:46.900]  have to open the breaker to the other transformers that are in the system. So we could do this by
[12:46.920 --> 12:53.420]  modifying parameters, which is the attack technique, and sending an unauthorized command message. So now
[12:53.420 --> 13:01.480]  we have a full story of how we're going to cause this thermal breakdown of the transformer. Now
[13:01.480 --> 13:06.380]  something that we have to consider is how do we can sustain this attack? What do we need to do
[13:06.380 --> 13:13.260]  to make sure that this attack can continue so we get our ultimate consequence? Well, here what we
[13:13.260 --> 13:18.660]  want to do is make the operator unable to react to the critical condition. And one of the ways we
[13:18.660 --> 13:23.660]  can do that is by causing a loss of view into the substation by manipulating communications.
[13:23.820 --> 13:29.420]  So the attack techniques that we can use here are block reporting message and alarm suppression.
[13:30.760 --> 13:37.620]  So now we know what we want to accomplish. We're not just fiddling around in a test bed environment
[13:38.400 --> 13:44.580]  with no ultimate goal. So what's next? So now we can build our attack scenario. We can think about
[13:44.580 --> 13:52.440]  what's our entry point, how do we find our targets, how do we sustain our attack, and how do we cause
[13:52.600 --> 13:58.020]  a failure, and even more. So in terms of entry points, maybe it's that we need an engineering
[13:58.020 --> 14:03.340]  workstation or to accomplish this attack or something that serves that function. And maybe
[14:03.340 --> 14:09.420]  we look for external remote services like a VPN connection or something that allows us to get
[14:09.420 --> 14:14.680]  connection to this engineering workstation. And then in terms of finding our target, we have to
[14:14.680 --> 14:21.660]  probably do some discovery. We could do network sniffing, we could do control device identification,
[14:21.660 --> 14:27.440]  or we could do network service scanning. And then to sustain our attack, what we want to do
[14:27.440 --> 14:34.820]  is maybe block reporting messages so that certain voltage or current values don't make their way up
[14:34.820 --> 14:41.300]  to the operator. Or we may want to do alarm suppression where we're stopping alarm messages
[14:41.300 --> 14:47.680]  from going up to an operator. And then finally, to cause our failure, we want to use impaired
[14:47.680 --> 14:56.560]  process control tactic techniques where we modify the overcurrent and thermal parameters,
[14:56.560 --> 15:03.020]  and we send commands at the wrong time to open breakers. So now we're starting to build a real
[15:03.020 --> 15:10.680]  story about what we want to do. So this is what a first pass at highlighting the relevant techniques
[15:10.680 --> 15:17.820]  looks like. As we build on to our story and kind of validate that we can cause the failures that
[15:17.820 --> 15:24.820]  we want, we may add additional techniques, things that go ahead, or we may have to fill in sort of
[15:24.820 --> 15:29.340]  gaps in knowledge that we have by using a technique. But this really serves as a basis of
[15:29.340 --> 15:36.760]  what we're doing in order to induce this failure. And something that we can do is dive really deep
[15:36.760 --> 15:42.320]  into particular techniques. So for instance, unauthorized command message. We may not just
[15:42.320 --> 15:46.920]  want to look at the description here. We may want to look at how adversaries have done this in the
[15:46.920 --> 15:52.640]  past. So we have the Murchishire attack as an example. We have the 2015 Ukrainian power grid
[15:52.640 --> 15:59.560]  attack. We also have particular implementations that we can look at, such as Indestroy or Stuxnet
[15:59.560 --> 16:05.120]  to understand how unauthorized command messages were used. And if that's not enough, we also have
[16:05.120 --> 16:11.140]  references. So you can dig even deeper into incident reports in order to understand exactly
[16:11.840 --> 16:19.920]  why an adversary used this technique, what they used it for. And this really helps to build the
[16:19.920 --> 16:27.100]  story around what we're doing within our testbed environment. So another thing we have to consider
[16:27.100 --> 16:33.400]  is data sources. And data sources are very valuable for defenders, but they should also
[16:33.400 --> 16:40.820]  be considered from the adversary standpoint as well. So what artifacts am I leaving behind as
[16:40.820 --> 16:47.120]  the adversary? We need to understand what our activities look like to the defender. This is
[16:47.120 --> 16:52.430]  very interesting when we're in a testbed environment. Where are we leaving behind?
[16:53.040 --> 16:58.280]  And most people look at network traffic in terms of defense, but there's also a lot of
[16:58.280 --> 17:05.160]  other rich data sources that are overlooked often. So host-based logs housed on embedded
[17:05.160 --> 17:11.800]  OT devices such as controllers are interesting. There's also asset management data associated
[17:11.800 --> 17:18.600]  with equipment under control that we can look at. So we've done a lot of surveys of devices
[17:18.600 --> 17:25.460]  to understand what data sources are on them. And we've come up with some high-level categories of
[17:25.460 --> 17:30.740]  data sources on low-level controllers. And I've kind of highlighted some of the ones that are most
[17:30.740 --> 17:36.100]  relevant to the scenario that we've already presented. So we may want to look at parameters
[17:36.100 --> 17:42.540]  on the device. And we could do this in integrity, periodic integrity checks on the parameters to see
[17:42.540 --> 17:48.720]  if they've remained the same, if they've gone outside of our original threshold. There's alarms
[17:49.600 --> 17:54.320]  that are generated at these devices and stored at these devices before they're sent. So we can
[17:54.320 --> 17:59.700]  look at those. There's event logs such as the sequential event recorder that contain a wealth
[17:59.700 --> 18:05.080]  of information about commands that have been executed or parameter changes or anything else
[18:05.080 --> 18:10.280]  like that. But we have asset management data. We can look at condition-based monitoring,
[18:10.280 --> 18:16.640]  understand particular parameters about that transformer such as thermal parameters to
[18:16.640 --> 18:20.520]  understand if it's overheating. And there's a number of other data sources that we can look
[18:20.520 --> 18:26.940]  at. But we want to be aware of what our activities look like from the defender's perspective.
[18:28.240 --> 18:34.860]  So here are some data source considerations that we can have as we're working in these
[18:34.860 --> 18:41.400]  environments. So is this data source able to be accessed via a standard interface, a documented
[18:41.400 --> 18:48.680]  interface? That's very important for access to that data source. What's the storage size of that
[18:48.680 --> 18:55.240]  source? Will it eventually roll over? Is there a lot of noise in the data source? Would it be hard
[18:55.240 --> 19:02.620]  for a defender to kind of look through it? And then are there standard commands that are available
[19:02.620 --> 19:09.100]  to just delete that data source? And then another thing we can consider is does the data source get
[19:09.100 --> 19:15.040]  replicated to other places? So if we're looking at a low-level protection relay, does it go up to
[19:15.040 --> 19:21.060]  another controller? The particular data sources that we're looking at,
[19:21.060 --> 19:25.940]  there may be aggregation points somewhere. So these are all things that we have to consider.
[19:26.060 --> 19:31.080]  So let's take another look at this overall process that I'm proposing to kind of structure your
[19:31.080 --> 19:36.920]  activities in the testbed. So first, we want to understand failures associated with your target
[19:36.920 --> 19:42.460]  system. For our target system, we were looking at a transmission substation, for instance.
[19:42.460 --> 19:49.500]  We want to build an attack scenario around your chosen failure scenario. So how do we induce this
[19:49.500 --> 19:55.340]  failure via cyber means? We want to build a story around it about what the adversary is actually
[19:55.340 --> 19:59.680]  trying to accomplish. What's the bigger goal? By researching how and why adversaries have caused
[19:59.680 --> 20:05.120]  similar failures in the past. We want to conduct the attack, and that includes implementing
[20:05.660 --> 20:10.860]  certain techniques and see if we can induce the failure in our system. This may take multiple
[20:10.860 --> 20:17.040]  times. We want to understand which data sources contain indicators of our attack.
[20:17.260 --> 20:21.280]  And then finally, if we're purple teaming or working together with blue teamers,
[20:21.280 --> 20:25.660]  we want to talk about our activities using the artifacts from our structured attack plan. So
[20:25.660 --> 20:31.480]  that may be, we show them what our failure looks like that we're trying to induce. We can show them
[20:33.080 --> 20:37.140]  a technique matrix with the right techniques highlighted, and we can share with them what
[20:37.140 --> 20:42.080]  data sources they should look at. And that could kind of help us to work together in order to
[20:42.570 --> 20:47.430]  figure out new things in the testbed environment and to communicate more efficiently.
[20:48.700 --> 20:57.300]  So some key takeaways. It can be very helpful to build a full story around your testbed activities
[20:57.300 --> 21:05.340]  by documenting failure and attack scenarios. So sometimes the reaction is just to hop on the
[21:05.340 --> 21:12.400]  testbed and to see what's going to happen and just go with it. But structuring our activities
[21:12.400 --> 21:19.740]  using ATT&CK for ICS can really help communicate what we're doing. And those things are all
[21:19.740 --> 21:25.160]  reusable in the future. So we also want to make sure we understand what artifacts we're leaving
[21:25.160 --> 21:33.500]  behind. And we want to work closely with defenders as purple teams. So really quick, because I'm
[21:33.500 --> 21:41.060]  almost out of time, what's new for ATT&CK for ICS? So on the horizon, we do have technique updates.
[21:41.140 --> 21:44.700]  So that's new adversary behavior and additional references.
[21:44.880 --> 21:50.260]  We're adding mitigations to each technique as well. So we have to consider all our stakeholders
[21:50.260 --> 21:56.160]  here. Device vendors are very important because a lot of the insecure by design
[21:57.960 --> 22:02.740]  problems that we see with these devices start there. So we want to tell them what they can do
[22:02.740 --> 22:07.440]  to address some of this adversary behavior, as well as like asset owners, what they can do at
[22:07.440 --> 22:15.040]  their level. It's going to include many references to standard bodies such as IEC, ISA, NIST. And it's
[22:15.040 --> 22:23.580]  really focused around adversary use of techniques and then how interfaces are used or what their
[22:23.580 --> 22:31.660]  functionality is, and then also the impacts. So the last couple of things are we're starting to
[22:32.300 --> 22:38.280]  integrate more with traditional ATT&CK tools that people are used to using. So
[22:38.280 --> 22:45.700]  ATT&CK for ICS will have a STIX representation and we're also integrating it
[22:45.700 --> 22:50.680]  with ATT&CK Navigator. So those are some things that you can look forward to in the future and
[22:50.680 --> 23:01.000]  hopefully help everybody to use the knowledge base more. So that's all I have. Please feel
[23:01.000 --> 23:05.580]  free to visit attack.mitre.org forward slash ICS to look at the knowledge base
[23:05.580 --> 23:08.440]  and reach out to me on Twitter if you have any questions.
